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DECISION ON APPEAL 



1 Filed May 23, 2000, titled "Method and Apparatus for Component 
to Service Mapping in Service Level Management (SLM)," which claims the 
benefit of Provisional Application 60/135,492, filed May 24, 1999. 

2 The two-month time period for filing an appeal or commencing a 
civil action, as recited in 37 C.F.R. § 1.304, begins to run from the decided 
date shown on this page of the decision. The time period does not run from 
the Mail Date (paper delivery) or Notification Date (electronic delivery). 
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This is an appeal under 35 U.S.C. § 134(a) from the Examiner's final 
rejection of claims 4 and 13-62, which are all of the pending claims. We 
have jurisdiction under 35 U.S.C. § 6(b). 

Oral argument was held on June 10, 2009. 

We affirm. 

STATEMENT OF THE CASE 

A. Appellant's invention 

The invention relates to service level management, wherein business 
processes are composed of services. A state of the service is defined by one 
or more service parameters, and the service parameters depend upon 
performance of network components that support the service, e.g., 
component parameters. The state of the service may depend, for example, 
on a collection of service parameter values for availability, reliability, 
security, integrity and response time. A service level agreement is a contract 
between a supplier and a customer that identifies services supported by a 
network, service parameters for the services, and service levels (e.g., 
acceptable levels) for each service parameter. See Abstract. 

B. The claims 

The independent claims before us are claims 4, 13, 27, and 49, of 

which claims 4 and 13 read: 

4. A method of monitoring a state of a service supported by a 
network, wherein the network includes a plurality of network 
components, wherein the service supports a business process under 
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service level management in association with a service level 
management domain, the method comprising the steps of: 

selecting one or more network components on which the 
service depends from among the plurality of network components; 

mapping the one or more selected network components to the 
service; monitoring the one or more selected network components to 
determine the state of the service; 

monitoring the state of the service to detect a change in the 

state; 

when the state of the service changes, determining a cause of 
the change in the state of the service by performing an action, the 
action comprising one or more of: 

invoking a routine to determine an operational characteristic of 
at least one of the selected network components, 

constructing a database query to determine the operational 
characteristic of at least one of the selected network components, and 

requesting a change to one or more parameters of at least one of 
the selected network components. 

13. A method for monitoring a service, the service supporting a 
business process under service level management in association with a 
service level agreement, wherein the service is monitored by an 
enterprise management system, wherein the business process depends 
on at least a portion of a network, the method comprising the steps of: 

mapping at least one component of the network on which the 
service depends to the service; 
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monitoring, at the enterprise management system, at least one 
parameter of the mapped network component, the at least one 
parameter indicating an operational characteristic of the network 
component that is indicative of a state of the service, wherein the state 
of the service is indicative of a current level of service relative to an 
agreed upon level of service in the service level agreement; 



determining, at the enterprise management system, the state of 
the service from the parameter of the monitored network component; 
and 

monitoring, at the enterprise management system, the state of 
the service to provide service level management for the business 
process that indicates the current level of service relative to the agreed 
upon level of service. 

Claims App., Br. 17-18. 

C. The references relied upon 

Taghadoss US 6,052,722 Apr. 18, 2000 

Glitho US 6,233,449 Bl May 15, 2001 

(filed Aug. 24, 1998) 
Yemini US 6,249,755 Bl Jun. 19, 2001 

(filed Jul. 15, 1997) 
Bhoj US 6,304,892 Bl Oct. 16, 2001 

(filed Nov. 02, 1998) 

D. The rejections 

Claim 4 stands rejected under 35 U.S.C. § 103(a) as unpatentable over 
Bhoj in view of Yemini. 

Claims 13-17, 19-35, 37-53, and 55-62 stand rejected under 35 U.S.C. 
§ 103(a) as unpatentable over Yemini, Bhoj, and Taghadoss. 



4 



Appeal 2009-000882 
Application 09/577,231 

Claims 18, 36, and 54 stand rejected under 35 U.S.C. § 103(a) as 
unpatentable over Yemini, Bhoj, and Taghadoss, further in view of Glitho. 

PRINICIPLES OF LAW 

"On appeal to the Board, an applicant can overcome a rejection by 
showing insufficient evidence of prima facie obviousness or by rebutting the 
prima facie case with evidence of secondary indicia of nonobviousness." 
In re Kahn, 441 F.3d 977, 985-86 (Fed. Cir. 2006) (quoting In re Rouffet, 
149 F.3d 1350, 1355 (Fed. Cir. 1998)). 

For an obviousness rejection, the combination of references must 
teach or suggest to a person of ordinary skill in the art all of the claim 
limitations. 35 U.S.C. § 103(a). 

Arguments not made are waived. See 37 C.F.R. § 41.37(c)(l)(vii) 
("Any arguments or authorities not included in the brief or a reply brief . . . 
will be refused consideration by the Board, unless good cause is shown."); 
In re Watts, 354 F.3d 1362, 1367 (Fed. Cir. 2004) ("Just as it is important 
that the PTO in general be barred from raising new arguments on appeal to 
justify or support a decision of the Board, it is important that the applicant 
challenging a decision not be permitted to raise arguments on appeal that 
were not presented to the Board." (Footnote omitted.)). Cf In re Baxter 
Travenol Labs., 952 F.2d 388, 392 (Fed. Cir. 1991) ("It is not the function of 
this court to examine the claims in greater detail than argued by an appellant, 
looking for nonobvious distinctions over the prior art."). 
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DISCUSSION 

Claim 4 - Bhoj and Yemini 
Issues 

Does the combination of Bhoj and Yemini teach: (1) "selecting one or 
more network components on which the service depends from among the 
plurality of network components"; (2) "mapping the one or more selected 
network components to the service"; (3) "monitoring the one or more 
selected network components to determine the state of the service"; and 
(4) "when the state of the service changes, determining a cause of the change 
in the state of the service by performing an action"? 

Contentions 

The Examiner finds that Bhoj teaches the steps of selecting, mapping, 
monitoring a network component, and monitoring a state of the service, but 
does not teach that when the state of the service changes, determining a 
cause of the change by one of the recited actions (Final Rej. 2-3; Ans. 4). 
The Examiner finds that Yemini teaches at column 8, lines 17-67, selecting a 
network component, mapping the network component to a service, 
monitoring the state of the component to detect a change in state, and when 
the state of the service changes, determining a cause of change in the state of 
the service by performing an action (Final Rej. 3; Ans. 4-5). The Examiner 
concludes that it would have been obvious to combine Yemini with Bhoj, 
"because mapping out where a problem is occurring in a network can aid in 
finding a resolution to fix said network problem" (Final Rej. 4; Ans. 5). 
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Appellant argues that neither Bhoj nor Yemini, alone or in 
combination, teaches, discloses, or suggests: (1) "selecting one or more 
network components on which the service depends from among the plurality 
of network components"; (2) "mapping the one or more selected network 
components to the service"; (3) "monitoring the one or more selected 
network components to determine the state of the service"; and (4) "when 
the state of the service changes, determining a cause of the change in the 
state of the service by performing an action." 

Appellant argues that neither Bhoj nor Yemini teaches "selecting one 
or more network components on which the service depends from among the 
plurality of network components." It is argued that Bhoj relates to SLAs and 
does not disclose or suggest that the SLAs include a selection of one or more 
network components (Br. 7-8). It is argued that Bhoj states that the 
components of an SLA include the parties, the service objectives, etc. 
(col. 6, lines 24-27), and none of these components teach selecting network 
components (Br. 8). It is argued that Bhoj precludes selecting network 
components in the manner claimed, because Bhoj prevents any one domain 
from having complete access to each of the data service systems; for 
example, Bhoj teaches providing an abstract view of the underlying data 
service system that is independent of the underlying implementation (Br. 8). 
It is argued that Yemini does not teach the "selecting" limitations (Br. 8-9). 

Appellant argues that neither Bhoj nor Yemini teaches "mapping the 
one or more selected network components to the service." It is noted that the 
Examiner relies on column 8, lines 17-67 of Yemini, where components 



7 



Appeal 2009-000882 
Application 09/577,231 

entered into the system are automatically "selected" to be monitored. 
However, Appellant argues that Yemini relates only to describing or 
representing network components without reference to services (Br. 9). It is 
noted that the Examiner also relies on Bhoj, column 9, lines 25-52 for 
"selecting" and "mapping" (Final Rej. 13). Appellant argues that this does 
not teach "selecting" because Bhoj "does not selectively choose one or more 
network components that a service depends on" (Br. 10) because it collects 
all management data, and does not teach "mapping" because Bhoj teaches 
providing an abstract view of the underlying data service system that is 
independent of the underlying implementation (Br. 10-11). 

Appellant argues that neither Bhoj nor Yemini teaches "monitoring 
the one or more selected network components to determine the state of the 
service." It is argued that Bhoj describes managing data between a 
requesting system and a responding system without giving the requesting 
system complete access to the responding data service system and that does 
not teach monitoring one or more selected network components (Br. 11). 
Appellant argues that Yemini does not teach or suggest actively monitoring 
components (Br. 11-12). 

Appellant argues that neither Bhoj nor Yemini teaches "when the state 
of the service changes, determining a cause of the change in the state of the 
service by performing an action ... for at least the reason that neither Bhoj 
nor Yemini, either alone or in combination, provide [sic] awareness over the 
'state of the service'" (Br. 12). 
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Facts - contents ofBhoj 

Bhoj describes that in independently administered control domains of 
a network, the system administrator in one control domain is not able to 
access another control domain to detect problems in that control domain, or 
to measure service performance of the other data service system unless the 
system administrator is given access to the other control domain (col. 2, 
11. 4-13). Bhoj relates to a management system for accessing selective 
management data and/or measurement information in accordance with a 
predetermined service agreement from a number of independently 
administered data service systems (col. 2, 11. 38-54). 

Figure 3 of Bhoj shows a data access network system 30 that includes 
a number of independently administered data service systems 31-33 
connected together via a network 34 (col. 3, 11. 53-61). The data access 
network system 30 includes a management system formed of a number of 
service management systems 31a-33a, each located in one the data service 
systems 31-33 (col. 3, 1. 62 - col. 4, 1. 1). Each service management system 
31a-33a can provide selective management data of the underlying data 
service system to another requesting service management system located in 
another data service system in accordance with a predetermined service level 
agreement between the two domains (col. 4, 11. 1-9). 

Bhoj describes that service level agreements (SLAs) are used to define 
agreements among the data service systems 31-33 to share resources, and to 
allow each of the data service systems to offer service quality guarantees to 
their respective customers (col. 5, 1. 67, to col. 6, 1. 4). An SLA is a contract 
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between the provider and the user that specifies the level of service expected 

during its term. An SLA can specify levels of service such as 100% 

availability of the backbone of the service provider, average monthly latency 

of not more than 85 milliseconds round- trip, notification of outage within 15 

minutes of an outage, installation by a quoted date, etc. (col. 6, 11. 28-61). 

The SLAs are converted into a contract specification (contract) to be used by 

the service management systems (col. 7, 11. 22-25). Bhoj states: 

A contract specification is derived from an SLA to indicate the service 
attributes that are meaningful for correct service behavior. The 
contract specification contains both the service attributes and the 
bounds within which the service attributes must stay in order for the 
service to behave in a desired manner. Attributes must both be 
quantifiable and measurable to be included in a contract specification. 

Col. 7, 11. 25-32. 

Bhoj describes that the "service model" of the corresponding data 

service system offers the agreed data service as follows: 

A service model of a data service system describes the service 
implemented by the corresponding data service system as well as the 
dependencies between the service components within the data service 
system. The service model identifies the various components of the 
data service system that enable the service. For example, if the 
service being managed is electronic mail, the service model would list 
the components as the e-mail server host, the networks connecting the 
e-mail host to the Internet, the e-mail application itself, the name 
server used to resolve host names to Internet addresses, and so on. 
The service model also expresses interdependencies that exist among 
the different components of the service. From the above e-mail 
example, all components identified in the service model should 
function properly for the e-mail service to work. The 
interdependencies capture the cause and effect between the 
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components of a service. The service model also identifies the 
measurements and metrics that are available from each component. 
Thus, the e-mail server could identify the number of e-mail 
transactions, and active measurements could be used to get an 
estimate of the response time seen by e-mail clients. ... As described 
above, a service model information includes customer dependent data 
and system dependent data. [Emphasis added.] 

Col. 9, 11. 25-52. 

Figure 5 of Bhoj shows a service management system 100, which can 

be one of the service management systems 31a-33a of Figure 3. The service 

management system 100 includes a service manager 200 connected to a 

contract repository 210 to receive contract templates. Bhoj describes 

connection to a local system 240: 

The service manager 200 is also connected to a local 
measurement/management system 240 (hereinafter referred to as local 
system 240). The local system 240 provides all management data of 
the data service system within which the service management system 
100 is located to the service manager 200. The local system 240 
collects all the management data from the local infrastructure and 
applications of the underlying data service system of the service 
management system 100. Based on the management data collected, 
the local system 240 provides an abstract view of the underlying data 
service system to the service manager 200 that is independent of the 
underlying implementation. The service manager 200 uses software 
and/or hardware tools as means to obtain the management data and to 
provide the abstract view. [Emphasis added.] 



Col. 11,11. 24-38. 

Bhoj further describes connection to a service model module 260: 

The service manager 200 is also connected to a service model 
module 260. The service model module 260 stores the service model 
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information of the data service system within which the service 
management system 100 is located. As described above, the service 
model includes a description of the service that the data service 
system of the service management system 100 is managing as well as 
the dependencies between the service components of the underlying 
data service system. 

Col. 12, 11. 19-27. 

Analysis 

Bhoj describes that the "service model of a data service system 
describes the service implemented by the corresponding data service system 
as well as the dependencies between the service components within the data 
service system" (col. 9, 11. 25-28). The service model is stored in the service 
model module 260, which is part of the service management system 100 of 
Figure 5 located in a data service system 31-33 of Figure 3. We interpret the 
"service implemented by the corresponding data service system" to 
correspond to the claimed "service supported by a network" in claim 4. 

Bhoj describes: 

The service model identifies the various components of the data 
service system that enable the service. For example, if the service 
being managed is electronic mail, the service model would list the 
components as the e-mail server host, the networks connecting the 
e-mail host to the Internet, the e-mail application itself, the name 
server used to resolve host names to Internet addresses, and so on. 

Col. 9, 11. 28-35. We find that identifying components that enable the 
service teaches the claim limitations of "selecting one or more network 
components on which the service depends from among the plurality of 
network components" and "mapping the one or more selected network 
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components to the service." That is, in the example, the e-mail service 
depends on the e-mail server host, the networks connecting the e-mail host 
to the Internet, and so on. These components are "mapped" to the e-mail 
service because they are identified with the service. "Mapping" only 
requires some association between components and the service, e.g., the 
"component-to- service parameter mapping" can be declaring that some 
component parameter is a service parameter (a one-to-one mapping) 
(Spec. 33: 12-21). 

Appellant argues that the SLA relied upon by the Examiner does not 
teach or suggest the "selecting" or "mapping" steps (Br. 7-9). It is argued 
that Yemini does not cure the deficiencies of Bhoj (Br. 8-11). It is argued 
that the Examiner's reasoning that the claim language could be interpreted as 
all network components being selected relies on the incorrect presumption 
that the service depends on every component of a network (Reply Br. 2). It 
is argued that the Examiner fails to identify any passage of Bhoj or Yemini 
that teaches the "selecting" and "mapping" steps (Reply Br. 3). Appellant 
argues (Reply Br. 3) that the Examiner's finding that Bhoj teaches 
"selecting" because "the system 'selects' [an] error to find out why it is in 
error" (Ans. 16) does not address the claim language of "selecting one or 
more network components on which the service depends." It is argued that 
Bhoj and Yemini do not disclose mapping (Br. 9; Reply Br. 4). 

We review the teachings of the references, not just the Examiner's 
reasoning. The Examiner pointed to column 9, lines 25-52, at page 13 of the 
Final Rejection, and we find that this part of Bhoj teaches the limitations of 
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"selecting" and "mapping" as discussed above. Bhoj teaches that "the 
management data are abstract or derived measurements computed from 
element level measurements" (col. 15, 11. 12-14), which indicates that 
components identified as enabling a service are selected and measured. 
Bhoj's teaching that the local system 240 provides an abstract view "that is 
independent of the underlying implementation" (col. 11, 1. 35) does not 
suggest that components are not identified and measured, but only that the 
component measurements are presented in an abstract view. 

Bhoj describes that the "service model also identifies the 
measurements and metrics that are available from each component" (col. 9, 
11. 41-43). The local measurement/management system 240 (local 
system 240) in Figure 5 "collects all the management data from the local 
infrastructure and applications of the underlying data service system of the 
service management system 100. Based on the management data collected, 
the local system 240 provides an abstract view of the underlying data service 
system to the service manager 200 that is independent of the underlying 
implementation." (Col. 11, 11. 29-35.) The measurement data is stored as 
attributes in a cache 301 in Figure 7 (col. 11, 1. 66 to col. 12, 1. 6). The 
system dependent data of the service model is stored in a system dictionary 
312, which controls the storage 301 to receive the management data (col. 14, 
11. 22-24). "[T]he management data are abstract or derived measurements 
computed from element level measurements." (Col. 15, 11. 12-14). Thus, 
Bhoj teaches "monitoring the one or more selected network components" by 
the local system 240. The fact that the local system 240 takes element 
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(component) level measurements and converts them into an abstract view is 
not precluded by the claim language. 

Appellant's arguments that Bhoj does not teach "monitoring" because 
there is no complete access to a data system is not persuasive. Bhoj provides 
monitoring within the data service system. 

Bhoj describes that in response to a request for verification, the 
service manager loads the contract template into the contract template 
module 302 and loads customer dependent data from the customer SLA 
database 310 into the verification interface 303. The contract template 
module causes the storage 301 to obtain the actual system management data 
of the underlying data service system, and "[t]hen the contract template is 
evaluated in the contract template module 302 by computing the values of 
the assertions defined in the contract template using the attribute values and 
customer- specific data (i.e., parameters, bounds, and thresholds)" (col. 15, 
11. 18-22). Since Bhoj monitors the network components to determine 
whether the performance meets the service contract, Bhoj teaches 
"monitoring the one or more selected network components to determine the 
state of the service" and "monitoring the state of the service to detect a 
change in the state." 

Bhoj reports the state of the service(s), that is, the extent to which the 
guarantees offered in the SLA are met. For example, Figure 10, although 
not described in Bhoj, shows the extent of service conformance for several 
service components, including ISP access and a mail system. 
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Bhoj does not describe "when the state of the service changes, 
determining a cause of the change in the state of the service by performing 
an action." The rejection relies on Yemini for this step and the specific 
actions. Yemini describes a method for determining the source of a problem 
in a complex system of managed components (Abstract), including computer 
networks (col. 1, 11. 15-22). The Examiner concludes that one of ordinary 
skill in the art would have been motivated to determine a cause of a problem 
with the state of the service in Bhoj using the method of Yemini. Appellant 
argues that the combination of Bhoj and Yemini does not teach or suggest 
"when the state of the service changes, determining a cause of the change in 
the state of the service by performing an action" for at least the reason that 
neither provides awareness over the "state of the service" (Br. 12). Bhoj 
determines monitoring the state of the service, and Yemini is only required 
to show that it was known to take action to determine the cause of a problem 
in a communication system. Appellant does not contest this teaching of 
Yemini or the motivation to combine in the Briefs. Although Appellant 
raised the issue of motivation to combine at the oral hearing, it was noted 
that this argument was not supported by the Briefs— we do not know what 
the Examiner would have said if presented with the argument. In 
conclusion, the limitation, "when the state of the service changes, 
determining a cause of the change in the state of the service by performing 
an action," would have been obvious over Yemini. 

Conclusion 
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The combination of Bhoj and Yemini teaches or suggests: 
(1) "selecting one or more network components on which the service 
depends from among the plurality of network components"; (2) "mapping 
the one or more selected network components to the service"; 
(3) "monitoring the one or more selected network components to determine 
the state of the service"; and (4) "when the state of the service changes, 
determining a cause of the change in the state of the service by performing 
an action." The rejection of claim 4 is affirmed. 

Claims 13-17, 19-35, 37-53, and 55-62 - Yemini, Bhoj, and Taghadoss 

Appellant argues that Yemini and Bhoj, alone or in combination, fail 
to teach or suggest the features of: (1) "mapping at least one component of 
the network on which the service depends to the service"; (2) "monitoring 
... at least one parameter of the mapped network component, the at least one 
parameter indicating an operational characteristic of the network component 
that is indicative of a state of the service"; and (3) "monitoring ... the state 
of the service to provide service level management for the business process 
that indicates the current level of service relative to the agreed upon level of 
service," as recited in claim 13, and the similar features in claims 27 and 49 
(Br. 12-14). It is argued that the Examiner errs in finding that "Taghadoss 
teaches associating a component of the network to the service" because 
Taghadoss is limited to information associated with the network resources 
themselves and not mapping to a service (Br. 13). 

We agree with Appellant that Taghadoss does not teach mapping to a 
service, but for the reasons discussed with respect to claim 4, we find that 
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Bhoj describes the argued limitations. Accordingly, the rejection of 
claims 13-17, 19-35, 37-53, and 55-62 is affirmed. 

Claims 18, 36, and 54 - Yemini, Bhoj, Taghadoss, and Glitho 

Appellant argues that Glitho fails to cure the deficiencies of Yemini, 
Bhoj, and Taghadoss with respect to the rejection of independent claims 13, 
27, and 49 (Br. 14-15). Because Appellant does not argue the separate 
patentability of claims 18, 36, and 54 but relies on the patentability of the 
independent claims, the rejection of claims 18, 36, and 54 stands or falls 
with the rejection of the independent claims. Accordingly, the rejection of 
claims 18, 36, and 54 is affirmed. 

CONCLUSION 

The rejections of claims 4 and 13-62 under 35 U.S.C. 103(a) are 
affirmed. 

Requests for extensions of time are governed by 37 C.F.R. § 1.136(b). 
See 37 C.F.R. § 41.50(f). 

AFFIRMED 

ere 

PILLSBURY WINTHROP SHAW PITTMAN, LLP 
P.O. BOX 10500 
McLEAN, VA 22102b 
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